Cell Manager and Initial Cell Setup

This section steps through a typical sequence of cell configuration tasks, detailing how Cell Manager is an effective OSF toolset surrogate and supplement.

Specify the registry policy attributes.
Populate the security registry.
Specify access controls for each new directory and inheritance controls for each directory's subordinate elements.
Start the Cell Manager processes that enable distributed management of the cell hosts.
Configure and start the client hosts.

Step 1: Specify the Registry Policy Attributes

Before an administrator can assign cell access privileges to a user or application, an account for the principal must exist in the security registry. Before populating the security registry with principal accounts, administrators must specify values for the 16 attributes that constitute the cell's registry policy. These values set some fundamental controls -- such as password format and length -that organizations (sets of associated principals) inherit by default when they are created. After determining registry-wide policy, administrators can specify more restrictive policies for individual organizations and principals.

Setting policy at any level using the OSF toolset is difficult. Different levels require different command sets. The following demonstrates how Security Manager simplifies registry policy definition:

Select the Maintenance -> Policy option. The attribute definition window opens; the window contains a labeled text field for each attribute.
Enter values in the fields.
Click the Apply button.

Step 2: Populate the Security Registry

Using the OSF toolset, adding a principal account to the security registry is a tedious process. First, the administrator specifies the name of the new principal. Then, as a separate step, the administrator creates the principal's account. These tasks involve invoking the rgy_edit interface then entering a series of obtuse subordinate commands.

For example:

->rgy_edit >>do p >>add sparky >>do a >>add sparky -g none -o dummy -pw "*****" -mp "*****" -pv -av >>quit

Security Manager streamlines this procedure:

Select the Account -> Add -> Principal option. The application prompts for the name of the new principal then opens an account definition window.
Enter the principal's group name, organization name, and password.
Click the Apply button.

Step 3: Structure the CDS Namespace

Administrators use directories to organize the namespace like a file system. This is the OSF toolset command for adding a directory to the CDS namespace:

->cdscp create directory full_namespace_pathname_of_directory [clearinghouse clearinghouse_name]

To verify that the directory was indeed created, the administrator would also have to enter this command:

->cdscp show object full_namespace_pathname_of_directory

The following procedure shows how a combination of Namespace Manager characteristics -- the namespace display, the point-and-click paradigm, and a task option menu -- simplifies the tasks of creating a namespace directory and verifying its existence:

Click the directory's parent in the display.
Select the Edit -> Add -> Directory menu option. A dialog opens that prompts for the new directory's name. Unlike the cdscp create directory command, the dialog does not require a complete pathname; the application derives the pathname from the selected parent.
Click the dialog's Add button. The directory's entry appears at the expected position in the display hierarchy. Thus, the display provides immediate visual feedback, leading the administrator through an incremental, error-free namespace build.

The application uses this same basic approach for adding and manipulating all types of namespace elements: directory replicas, clearinghouses, RPC servers, RPC profiles, profile elements, RPC groups, group members, and soft links.

Step 4: Specify Access Controls for the New Directories

The mechanism for protecting a cell resource, such as a namespace directory, is an access control list (ACL). An ACL specifies the principals and security groups that can access the resource. Administrators assign specific permissions to each principal and group in the list.

Most cell objects have more than one ACL. For example, each clearinghouse and RPC server has an ACL that controls access to the namespace entry and an ACL that controls access to the actual object that the entry represents. Each namespace directory is associated with three different ACLs:

Basic ACL, which controls access to the directory.
Initial Directory ACL, which is the initial Basic ACL and Initial Directory ACL that the directory's child directories inherit by default when they are created.
Initial Object ACL, which is the initial Basic ACL that the directory's child objects inherit by default when they are created.

The OSF toolset provides an interactive interface, acl_edit, for creating, listing, and updating ACLs. Multiple ACLs for the same cell resource make acl_edit that much more difficult to use. Not only must administrators remember which ACLs apply to a specific namespace element, listing and editing each ACL require completely different command iterations.

->acl_edit full_namespace_pathname_of_directory -l ->acl_edit full_namespace_pathname_of_directory -ic -l ->acl_edit full_namespace_pathname_of_directory -io -l

Namespace Manager obviates these problems:

Click the target directory's entry in the namespace display.
Select the Edit -> Attributes option. A window opens that displays the directory's CDS attributes. (Administrators can review and edit the attribute list before proceeding.) The window contains a labeled button for each relevant ACL.
Click the button that corresponds to the ACL you want to access. That ACL's display/edit window opens. (All of Cell Manager's editing windows are consistent in form and function.)

Step 5: Start the Distributed Management Processes

Cell Manager's remote administration capabilities are carried out by two daemons: the Host Agent and the Collector Agent. The Host Agent, which can be installed and started on all cell hosts, performs DCE host configuration and process manipulation tasks and reports status to the graphical user interface. The Collector Agent, which must be installed and started on only one host, manages the cell's host list and monitors the status of each host's DCE processes. The following figure depicts the agent communication flow.

Host and Collector Agent Communication (image = about 6.5K)

After administrators install the daemons and start them the first time, the daemons can be booted automatically as part of each host's start-up sequence.

Step 6: Configure Hosts as DCE Clients

If scripts supplied by the core DCE vendor do not configure the cell's client hosts, the administrator has to configure each client. Administrators must configure each host locally using the command set provided by the DCE vendor. (Each vendor provides a different set, which is an administrative issue in and of itself.

Configuration Manager provides a simple two-step operation to configure multiple client hosts remotely and simultaneously:

Select the DCE -> Add Host to DCE option. A confirmation dialog opens listing all of the hosts in the cell that are in the proper state for being configured. The dialog supports point-and-click list editing.
Click the dialog's Configure button. The application ensures that the operation is secure by prompting for the password that the administrator entered to log in to Cell Manager.

After configuring the client hosts, the application displays each host's DCE status information as shown in the following example display. (Similar status displays are available on demand by selecting one or more hosts and clicking a button: DCE status for configured processes, DTS status, cached clearinghouse status, and CDS clerk status, and CDS server status.)

Example DCE Status Display

    Host Name  rpcd     dtsd     sec_clientd  cdsadv

    -------------------------------------------------------

    neko       active	active	 active	     active

    
    rhea       active	active	 active	     active

Configuration Manager uses this same basic approach for unconfiguring hosts and starting and stopping their DCE processes. In each case, the application assesses the hosts' current state to determines which hosts qualify for the requested operation.

[Prev] [Next] [TOC]

Last updated and validated Tue 30 Jan 96 by nita@halsoft.com